Today, computer operating systems commonly used on personal and enterprise computing devices use several layers of abstraction to allow software to execute consistently on any number of different computer hardware configurations. To achieve this, operating system components and applications are organized in layers. Software in each layer communicates with software in layers above and below it. Higher layers provide increasing degrees of abstraction, ending with the application program used by a user.
Conveniently, application programs need not communicate with hardware directly, and need only communicate with the operating system, or special purpose software modules and other applications which ultimately communicate with the operating system. The operating system, in turn communicates with lower level layers to cause hardware to act as requested by the application programs.
Device driver software, on the other hand, is software typically used by the operating system to provide a software interface to a particular hardware device. Device driver software functions as an abstraction layer isolating the details of how hardware operates from the operating system and application programs, thereby increasing the portability of higher level programs and libraries. This form of abstraction allows applications and operating systems to be utilized with many different hardware devices without modification provided a driver compatible with the particular hardware device is available.
This layered approach provides numerous benefits: it simplifies the creation of applications by programmers; it allows software to operate nearly identically using a multitude of hardware; and it facilitates upgrades to drivers and the operating system.
At the same time, programmers are constrained somewhat by the hardware access supported by the operating system.
The current Microsoft Windows™ programming environment, in particular, allows only certain parameters of graphics adapter drivers to be changed using the available graphics driver application programmer interface (“API”). As well, changes to driver parameter settings do not affect application settings dynamically. Instead, changes in driver parameters are typically only recognized as a consequence of certain events.
This, in turn, does not allow an end-user to preview changes to certain driver parameters before these are committed to all applications.
Accordingly, a method of dynamically previewing changes in certain hardware driver parameter settings, and an application allowing their preview are needed.